kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19950528-19950726/[e-mail]_Fri Jun 30 10:46:31 1995.msg

Internet Message Format | 1995-07-31 | 5KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA17160
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Sat, 1 Jul 1995 16:07:52 -0400
Received: by apakabar.cc.columbia.edu id AA21482
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 1 Jul 1995 16:07:51 -0400
Newsgroups: comp.dcom.modems,comp.protocols.kermit.misc
Path: news.columbia.edu!panix!tinman.dev.prodigy.com!prodigy.com!newsjunkie.ans.net!howland.reston.ans.net!news.sprintlink.net!uunet!in1.uu.net!sangam!rdc.ernet.in!shuvam
From: [e-mail] (Shuvam Misra)
Subject: Re: Improved modem dialing for C-Kermit
Message-Id: <[e-mail]>
Organization: Ravi Database Consultants Private Limited, Bombay, India
Date: Fri, 30 Jun 1995 10:46:31 GMT
References: <3seuml$[e-mail]> <3shhv6$[e-mail]> <3sl921$[e-mail]> <3sma6k$[e-mail]>
Followup-To: comp.dcom.modems
Lines: 67
Xref: news.columbia.edu comp.dcom.modems:100264 comp.protocols.kermit.misc:3092
Apparently-To: [e-mail]

In article <3sma6k$[e-mail]>,
Frank da Cruz <[e-mail]> wrote:
>In article <3sl921$[e-mail]>, Leslie Mikesell <[e-mail]> wrote:
>>In article <3shhv6$[e-mail]>,
>>Frank da Cruz <[e-mail]> wrote:
>
>>The Devices and Dialers files in HDB uucp provide a general solution
>>to these questions.  Rather than re-invent that solution or provide
>>less general hard-coded knowledge of specific devices ... [deleted]
>
>But aren't we moving away from the timesharing world, where a bunch of
>users on the same machine are competing for the same pool of dialout
>ports.  An increasing proportion of C-Kermit users has total control of
>the computer they are using.

Quite true, but the other class of users is still quite large. There
must be -- thousands? tens of thousands? -- of shared modems out there
in educational institutions and small organizations? In my company of
less than ten people, we have two modems which all of us access. I
guess this is not yet very uncommon. Moreover, the issue doesn't stop
there, as I'll explain in the next few paras..

Since we cannot use the table-driven approach, it is impossible to use a
common configuration file, e.g. a sort of /etc/modemcap. Even if there
are only ten thousand sysadms managing shared modems all over the world,
it's not easy for them to use each other's work, unless they can just
add to a growing config file which can be exchanged and refined freely.
To do this, of course, we need to finalise on the file format first. I
was going through the config info required by FlexFax. The kind of
details it needs is enormous. If all that could be put into a globally
standardized file format, all modem-related programs could use it.

Basically, I look at the modem config problem in a more generalised way.
You were talking about the problem of one sysadmin managing a pool of
shared modems on one machine. Such a person will have to inform only her
own set of users. This problem disappears in the single-user world where
each person configures his or her own modem.  But the overall problem
remains; why can't all my modem programs and all your modem programs on
all your operating systems use a common /etc/modemcap? Ideally, I'd like
to configure my ZyXEL modem after a lot of trouble, and just write the
config info in a sort of globally understood syntax, and everyone else
could use it. I think this could even be OS-independent. An ASCII file,
together with its access library in C, can be ported to any OS. I am
sure there are serial-port-related issues which are OS-dependent, but I
suspect even a lot of that could be parameterized.

There is nothing very original about my idea; I believe that if
/etc/termcap can work, why not /etc/modemcap? In such a file, there
would be one entry for a modem type called "_DEFAULT_" or some such.
All modem definitions would need to specify only the departure from
this default. This _DEFAULT_ would define a simple Hayes-compatible
modem. And modem definitions would be organized in heirarchies, like
in /etc/termcap. Sort of "base class" and "derived classes". I guess
more than 90% of config info for ZyXEL models will be in one "base
class" for ZyXEL modems, with small derivatives for each specific
model... And in my ideal world, modem manufacturers will supply
/etc/modemcap entries to customers...

Hope to have the (gaping?) holes in my scheme shot down.. :)

Shuvam

--
-- shuvam misra ------------------------------- [e-mail] --
-- systems administrator -------------------------- [phone] --
----------------------------------------------- fax [phone] --
----------- "Linux: the choice of a GNU generation" ------------------